The OWNERSHIP filter makes sense to me, and is one valid way of proceeding here.

My inclination would be to generalize this beyond just OWNERSHIP: all grants given BY the current user (=role), and NOT TO the current user (=role):

for row in grants_table:

    # three relevant columns
    grantee = row['grantee_name']
    privilege = row['privilege']
    granted_by = row['granted_by']

    # super gross, but it works
    # (this is the value from profiles.yml)
    current_role = self.connections.profile.credentials.role
    
    if (
        # granted BY the current role
        granted_by.lower() == current_role.lower() and
        
        # NOT granted TO the current role
        grantee.lower() != current_role.lower()
    ):
        ...

We don't need this here if apply_grants is already happening within create_or_replace_view() (here)

Okay, let's talk about should_revoke!

View + table:

• should_revoke = False, because grants are NOT carried over
• UNLESS the user has explicitly opted into the copy_grants config, in which case they are
• What should our behavior be? I think it should be conditional based on copy_grants, and this could simply be should_revoke = copy_grants. Either both are False or both are True.

Incremental, seed, snapshot: These have the added questions of: Are we building this table for the first time? Are we fully replacing (full-refreshing) it? If we ARE fully replacing it, we should use the exact same conditional logic (based on copy_grants) to determine

If we are going to have conditional logic based on copy_grants, it requires us to have different logic for different models, rather than a single True/False setting for the entire adapter. That's a vote in favor of putting this logic into the materialization, rather than an adapter method, as discussed in dbt-labs/dbt-core#5369 (comment)